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Abstract. Algorithms for computing on encrypted data promise to be a funda- 
mental building block of cryptography. The way one models such algorithms has a 
crucial effect on the efficiency and usefulness of the resulting cryptographic 
schemes. As of today, almost all known schemes for fully homomorphic 
encryption, functional encryption, and garbling schemes work by modeling 
algorithms as circuits rather than as Turing machines. 
As a consequence of this modeling, evaluating an algorithm over encrypted data is 
as slow as the worst-case running time of that algorithm, a dire fact for many tasks. 
In addition, in settings where an evaluator needs a description of the algorithm 
itself in some “encoded” form, the cost of computing and communicating such 
encoding is as large as the worst-case running time of this algorithm. 
In this work, we construct cryptographic schemes for computing Turing machines 
on encrypted data that avoid the worst-case problem. Specifically, we show: 
— An attribute-based encryption scheme for any polynomial-time Turing 
machine and Random Access Machine (RAM). 
— A (single-key and succinct) functional encryption scheme for any polynomial- 
time Turing machine. 
— A reusable garbling scheme for any polynomial-time Turing machine. 


These three schemes have the property that the size of a key or of a garbling 
for a Turing machine is very short: it depends only on the description of the 
Turing machine and not on its running time. 

Previously, the only existing constructions of such schemes were for depth-d 
circuits, where all the parameters grow with d. Our constructions remove 
this depth d restriction, have short keys, and moreover, avoid the worst-case 
running time. 


— A variant of fully homomorphic encryption scheme for Turing machines, 
where one can evaluate a Turing machine M on an encrypted input x in time 
that is dependent on the running time of M on input x as opposed to the 
worst-case runtime of M. Previously, such a result was known only for a 
restricted class of Turing machines and it required an expensive preprocessing 
phase (with worst-case runtime); our constructions remove both restrictions. 

Our results are obtained via a reduction from SNARKs (Bitanski et al) and an 
“extractable” variant of witness encryption, a scheme introduced by Garg et al.. We 
prove that the new assumption is secure in the generic group model. We also point 
out the connection between (the variant of) witness encryption and the obfuscation 
of point filter functions as defined by Goldwasser and Kalai in 2005. 


Keywords: Computing on encrypted data; Functional encryption; Fully homo- 
morphic encryption; Turing machines; Input-specific running time. 


1 Introduction 


Almost all known cryptographic constructions for computing on encrypted data model 
algorithms as circuits instead of Turing machines.! The most notable such constructions 
are fully homomorphic encryption, attribute-based encryption, functional encryption, 
and garbling schemes. There are at least two unfortunate consequences of modeling 
algorithms as circuits. 

The first consequence of using circuits is that evaluating an algorithm A on encrypted 
data is at least as slow as the worst-case running time of algorithm A on all inputs of 
a certain size. Ideally, the runtime of A on input x should be the time A takes to run 
on x. The reason for this slowdown is that all the known transformations from Turing 
machines to circuits essentially work by unrolling loops to their worst-case runtime, 
and by considering all branches of a computation. Even if the cryptographic overhead 
of these schemes were zero, such worst-case runtime can still make the computation 
prohibitively slow: for example, the simplex algorithm for linear programming runs in 
polynomial time on most instances one encounters in practice, but in exponential time 
on rare inputs. 

Some schemes for computing on encrypted data (such as functional encryption and 
garbling schemes) require the evaluator to obtain a token for an algorithm A in order to 
run A on the encrypted data. The second consequence of modeling algorithms as circuits 
is that the size of the token is as large as the running time of the algorithm, instead of 
depending only on the description of the algorithm, which can be much shorter. 

The earliest example of using circuits for computing on encrypted data is Yao’s 
secure function evaluation protocol [Yao86] which takes as input any polynomial 
time computable function f — specified by a circuit — and outputs a “garbled 
circuit” with the same input-output functionality. Such worst-case runtime also 
affects known two-party and multi-party protocols for general secure function eval- 
uation [Yao86,GMW87,BGW88,CCD88]. 

More recent constructions for computing on encrypted data also use circuits to 
model computation and thus suffer from the worst-case slowdown: fully homomorphic 
encryption schemes (FHE) [Gen09,BV11a,BV11b,BGV12,Bra12], attribute-based en- 
cryption (ABE) schemes [GVW 13,GGHT 13b,GGH 13a], and functional encryption (FE) 
schemes for general functions [SS10,GVW12,GKP* 13]. 

In this work, we construct cryptographic schemes for Turing machines, thus removing 
the two major limitations of circuits discussed above. We construct attribute-based 
encryption, single-key (succinct) functional encryption, reusable garbling schemes, and 
a version of FHE for polynomial-time Turing machines. For each of these schemes, we 
show that the time to evaluate a Turing machine M on an input x is input specific: it 
depends on the runtime of M on x and not on the worst-case runtime of M on all inputs 
of length n where n = |x|. Moreover, we show that the token an evaluator needs to 
run a Turing machine M on encrypted data is short: its size depends on the size of the 
description of the Turing machine M and not on M’s runtime. Our schemes are for 


' An exception is the garbling scheme of [LO12] for RAMs, but this scheme also suffers from 
worst-case running time problem (see Sec. 1.1). 


both uniform and non-uniform Turing machines (so in particular, they can compute any 
circuits). 

Since the evaluator can compute a Turing machine M in input-specific runtime, 
it means that the evaluator necessarily learns the runtime of M on specific inputs. 
In some of the schemes we consider, such as ABE, such runtime provides no new 
information to the evaluator. In other schemes, such as FE, the evaluator could learn 
additional information from the runtime. This is why we also provide a second functional 
encryption scheme that does not leak the runtime and runs in worst-case time, while still 
benefiting from the Turing machine model because it has short tokens. Depending on 
how one weighs leaking runtime versus worst-case performance, one can choose one 
scheme or the other. 

Our schemes are based on extractable witness encryption, a variant of the witness 
encryption notion of Garg et al. [|GGSW 13]. We show how to obtain such an extractable 
witness encryption scheme using the construction of Garg et al. [GGSW13], by 
strengthening their assumption with a knowledge property. We prove the new assumption 
secure in the generic group model. Interestingly, we show that extractable witness 
encryption is closely related to (weakly) obfuscatable point-filter functions [GK05]. 


1.1 Our results 
We now explain our results in detail. 


Attribute-based encryption (ABE) for Turing machines and RAMs. Attribute-based 
encryption schemes, originally defined by Sahai and Waters [SW05], allow a user holding 
the master secret key msk to generate a function key sk ¢ for any predicate f of his choice, 
where sky does not hide f. Using the master public key mpk, anyone can encrypt a 
message m with respect to an “attribute” x: such a ciphertext is denoted by Enc(a; m). 
The ciphertext Enc(x;m) does not hide x, and hides only m. Given a function key sk 
and a ciphertext Enc(x;m), one can compute m if f(x) = 1. On the other hand, if 
f(x) = 0, ABE leaks no information about m and provides semantic security. 

Attribute-based encryption is a powerful primitive and has thus received significant 
attention [GPSW06,LOS*10,LW12,GVW13]. The state-of-the-art is the scheme of 
Gorbunov et al. [GVW 13]: based on the LWE assumption, they construct an ABE for 
the class of all circuits of depth at most d, where the efficiency of the scheme (such as 
the size of the ciphertexts) decreases polynomially with d. In concurrent work, Garg et 
al. constructed ABE schemes with similar properties [GGH™ 13b], and an ABE scheme 
with large ciphertexts [GGSW 13], both from candidate multi-linear maps. 

In this work, we construct an attribute-based encryption scheme for all circuits, 
with no restriction on the depth. More importantly, we model functions as Turing 
machines (with possibly non-uniform advice), as opposed to circuits as in previous 
work. Computing a function key ską, corresponding to a Turing machine M, takes 
roughly linear time in the size of the description of M, independent of the runtime of M. 
Moreover, given ską and Enc(x; m) where f(a) = 1, one can compute m in time that 
depends only on the time it takes to compute M on input x as opposed to the worst-case 
running time of M. We prove the security of our scheme with respect to a non-adaptive 


simulation-based definition (we refer the reader to Sec. 3 for details). We then show that 
a modification of our construction provides ABE for RAMs. 


Theorem 1 (Informal). There exists an attribute-based encryption scheme (as defined 
in Defs. 3, 4) for (uniform or non-uniform) polynomial-time Turing machines and RAMs 
from the assumptions in Sec. 1.2. 


Interestingly, we show how to extend our ABE scheme beyond Turing machines and 
RAMs: for example, an evaluator can choose by himself which Turing machines to run 
on the ciphertexts, as long as they satisfy some property expressed in a function key. 


Functional encryption (FE) for Turing machines. Functional encryption, formalized 
by Boneh, Sahai and Waters [BSW11], is a generalization of attribute-based encryption. 
In functional encryption, a user holding the master secret key msk can generate a function 
key sk corresponding to a function f; then, anyone having a ciphertext Enc(x) and a 
function key sk can compute f(z), but learns nothing else about the input z. 

So far, the only many-keys FE schemes known (schemes in which the secret key 
owner can securely release an unbounded number of function keys) are for the inner- 
product predicates [KSW08,SSW09]. For general functions, Agrawal et al. [AGVW12] 
showed that there does not exist a many-keys FE scheme if one wants to achieve a natural 
simulation-based security definition, so the natural question was to construct a single- 
key functional encryption scheme for general functions. Sahai and Seyalioglu [SS10], 
Gorbunov et al. [GVW12], and Goldwasser et al. [GKP* 13] constructed such schemes 
for circuits. The work of Goldwasser et al. [GKP* 13] is the first to provide succinct 
ciphertexts: the ciphertext size is much smaller than the circuit size; they constructed 
a succinct single-key FE scheme for any depth d circuit, where the parameters of the 
scheme grow with d (but are independent of the circuit size). 

In this work, we not only remove this depth-d restriction, but we model functions as 
(possibly non-uniform) Turing machines, as opposed to circuits as in prior work. Our 
schemes have short function keys: computing the function key of a Turing machine M 
depends only on the size of M and does not depend on the runtime of M. We note that 
in all previous schemes for general functions the size of a function key for a function f 
grows (at least linearly) with the worst-case runtime of f. We note however, that as 
opposed to our ABE scheme, in a functional encryption scheme, given Enc(2:) and skw, 
the time it takes to compute M (x) must be proportional to the worst-case runtime of M, 
since the runtime of M on input x may leak sensitive information about x. However, 
if one is willing to slightly relax security and allow leaking the runtime of M on the 
secret input x, then we also show how to construct a decryption algorithm that has 
input-specific runtime (i.e., runs in time polynomial in the runtime of M on input x) — 
we denote this by input-specific runtime functional encryption. 


Theorem 2 (Informal). There exists a single-key (succinct) functional encryption 
scheme and input-specific runtime functional encryption scheme for (uniform or non- 
uniform) polynomial-time Turing machines from the assumptions in Sec. 1.2. 


> Their lower bound does not apply to weaker security definitions. 


Variant of FHE for Turing machines. We construct a variant of FHE where one can 
evaluate a Turing machine M on a ciphertext Enc(x) in time that depends on the runtime 
of P on the specific input x. We naturally call this scheme input-specific FHE. At first 
glance, this may seem impossible, since revealing the runtime of P on input x may 
reveal secret information about x. However, for many Turing machines M, revealing 
only the runtime of M is not harmful, and it can provide significant efficiency gains. 
Our construction is an improvement of Goldwasser et al. [GKP* 13] who showed 
how to construct input-specific runtime FHE from single-key functional encryption. As 
in Goldwasser et al. [GKP* 13], we also encrypt a Turing machine M and g together 
into a token tkay,. Producing such a token depends only on the size of x and M, and 
not on the running time of M. The evaluator can use tkm,» and public information to 
compute M (x) in input-specific time. The reason we provide a token for M at all is for 
security: the FHE evaluator must no longer be able to evaluate TMs of its choice on the 
encrypted inputs because the running time of those TMs can leak the input entirely. We 
combine M and z in tkm,x for a technical reason stemming from the fact that the FE 
scheme we use in the construction is single-key — we elaborate in our full paper. 
Comparing to [GKP* 13], we make the following improvements: 


- Remove costly preprocessing. [GKP* 13] had an expensive preprocessing phase 
taking as long as the worst-case runtime. With our scheme, the preprocessing is 
cheap: polynomial in the size of the TMs and independent of the worst-case runtime 
(so in fact it can be performed in the online phase). 


— Works for any polynomial-time Turing machine. Because the ciphertext size 
in [GKP*13] depended on the depth of the worst-case circuit representation of 
the class of Turing machines, [GKP* 13] only allowed a restricted class of Turing 
machines: the class of TMs that can be expressed by shallow-depth circuits (e.g., 
log-space Turing machines). Our result does not have the depth restriction and thus 
applies to any class of Turing machines with runtime upper-bounded by a polynomial. 


Theorem 3 (Informal). There exists an input-specific-runtime fully homomorphic 
encryption scheme for (uniform or non-uniform) polynomial-time Turing machines 
based on the assumptions in Sec. 1.2. 


Reusable garbling scheme for Turing machines. Garbling schemes, introduced in the 
seminal work of Yao [Yao086], have found many applications in cryptography. In such 
schemes, a user can “garble” a function f and then encode an input x in a token tkz. 
Given a garbling of f and a token tkz, one can compute f(x), but learns nothing else 
about f or x. Some works also considered an authenticity property [BHR12,GVW13], 
on which we do not dwell. Traditional garbling schemes are one-time: they are secure 
only if an adversary gets a token for at most one input. A reusable garbling scheme is 
secure when the adversary gets an unbounded number of tokens. 

In known garbling schemes (even non-reusable ones), the size of the garbling is as 
large as the worst-case runtime of f. Often, the reason is that programs are modeled 
as circuits, and the size of the garbling is at least the size of the corresponding circuit. 
In this work, we construct a (reusable) garbling scheme for (uniform or non-uniform) 
Turing machines, where the size of the garbling depends only on the size of the Turing 
machine, and is independent of its runtime. The work of [LO12] is an exception from the 


circuit model: they model computation as RAM, but their scheme still has large garbling 
size, at least as large as the worst-case running time. 

As in our FHE and FE schemes, if one allows leaking the runtime of M on input x, we 
can additionally avoid worst-case evaluation time and obtain an input-specific reusable 
garbling scheme: given a garbling for a Turing machine M and a token tkg, the time to 
compute M (x) is polynomial in the runtime of M on the specific input z. 

Goldwasser et al. [GKP* 13] provide a reusable garbling scheme only for depth 
bounded circuits; our schemes remove the depth dependency, provide short garbling size, 
and can additionally avoid worst-case running time. 


Theorem 4 (Informal). There exists a reusable garbling scheme and an input-specific 
reusable garbling scheme for (uniform or non-uniform) polynomial-time Turing machines 
from the assumptions in Sec. 1.2. 


In summary, our work models computation on encrypted data as Turing machines 
and thus avoids the worst-case “curse” for a set of well-known cryptographic notions. 


Remark 1. Interestingly, we can easily overcome the worst-case curse for interactive 
tasks such as two-party and multi-party protocols as follows. To securely evaluate a 
Turing machine M, we evaluate the Turing machines M1, .. . , Masog n) sequentially, 
where M; runs the Turing machine M for 2° steps and outputs M’s answer if M halted 
in 2° steps, otherwise L. To evaluate M;, we simply use existing multi-party protocols. 
Note that the circuit size for M; is poly(2'), and since we halt the computation as soon 
as we get anon- answer, the protocol runs in input-specific time. The reason we can 
overcome the worst-case curse in this manner is that interaction is allowed. In this work, 
we focus on non-interactive tasks, which are more challenging. 


1.2 Our Assumptions 


Our schemes rely on two assumptions: extractable witness encryption and the existence 
of SNARKs. 

Extractable Witness Encryption. The recent work of Garg et al. [GGSW13] constructs 
a new primitive called witness encryption (WE). Such a scheme is associated with some 
NP complete language L. Given an instance x and a message m, any user can encrypt m 
with respect to x; this is denoted by Enc,(m). Given Enc,(m) and a valid witness w 
of x, any user can decrypt x efficiently. On the other hand, if x is not in the language, 
the scheme provides semantic security. 

In our work, we additionally assume that the [GGSW 13] scheme is extractable: if 
an adversary can break semantic security for an instance x, an extractor can extract the 
witness for x. Such an extractable scheme can be constructed from an extractable version 
of the [GGSW 13] assumption (called extractable DGE No-Exact-Cover assumption) so 
we strengthen their assumption. While we state our assumption in a decisional form for 
simplicity, the search version of the assumption suffices for our schemes because we can 
use hard-core predicates to mask the one bit we care to hide (m). 

We validate our assumption in the generic group model: we prove that no polynomial- 
time adversary can break the assumption in the generic group model where adversaries 


can only use multilinear map operations as a black-box. We refer the reader to our full 
paper for more details on the assumption, and emphasize that we view our result as a 
reduction from any extractable witness encryption scheme, as opposed to a result that is 
tied to the specific computational assumption. 

We show that, interestingly, extractable witness encryption is highly related to another 
task that was already well-known in the cryptographic literature: (weakly) obfuscating 
point-filter functions, defined by Goldwasser and Kalai [GKO5]. Informally, point-filter 
functions for a language L € NP with witness relation Rz are a class of functions 
{őz b}, indexed by a string x € {0, 1}” and a bit b € {0, 1} that behave as follows: 


(x, 5), if (z, w) € Rx, 
(x, L), otherwise. 


ôs p(w) = { 


It can be shown that extractable witness encryption is indeed equivalent to (weakly) 

obfuscating point filter function. Thus, the former implies the consequences of the 
later regarding the impossibility of obfuscation for a wide range of natural tasks based 
on [GKO5]. See our full paper for more details. 
The existence of SNARKs (Succinct Non-interactive Arguments of Knowledge). 
Bitansky et al. [BCCT13] construct SNARKs in a generic way (via a reduction from 
weaker SNARKs). Their work is based on “knowledge of exponent assumptions”, and 
the existence of collision resistant hash functions. 

If we remove SNARKs from our constructions, we still obtain novel schemes over 
prior work because the sizes of the function keys and of the garbling remain short, 
linear in the size of the Turing machine. Without SNARKs, though, the loss is that the 
ciphertext size grows with the running time of the Turing machines. 


Our FE, FHE, and reusable garbling schemes additionally rely on the existence of a 
fully homomorphic encryption scheme, which can be obtained from the LWE assumption 
with circular security [BGV 12]. 


1.3 Techniques overview 


ABE for Turing machines. The main technical challenge in this work is constructing 
an ABE scheme for Turing machines. 

Our construction starts with witness encryption and a signature scheme. The function 
key for a Turing machine M is simply a signature of M. The master secret and public 
keys generated during setup are the secret and verification keys (SigSK, VK) for the 
signature scheme. To encrypt a bit b with respect to a (public) attribute x, we compute a 
witness encryption Encs» (b), where x* = (x, VK) and where a valid witness for x* is a 
tuple (M, o,r), where M is a Turing machine, o is a signature of M using SigSK, and 
m the tableau of the computation, which can be interpreted as a “proof” that M (x) = 1. 

Loosely speaking, the security proof proceeds as follows. Suppose there exists a 
successful adversary A for our ABE scheme. Then, given Enc,» (b), the ABE encryption 
of a random bit b, and several secret keys skm, = g; such that M; (x) = 0, A succeeds 
in guessing b with non-negligible advantage. The security of the extractable witness 
encryption implies that there exists a poly-time extractor that extracts a valid witness 
from A with non-negligible probability. Recall that a valid witness is a triplet of the 


form (M*,o*,2*) where o* is a valid signature of the Turing machine 1/* and 7* is a 
proof that M*(x) = 1. Note that since M;(a) = 0 for every i, it must be the case that 
M* # M, which contradicts the unforgeability of the signature scheme. 

Unfortunately, this idea does not quite give us the results we want. The reason is 
that the time to check a witness for an instance 7* = (a, VK) is very long because it 
involves checking the tableau m of M on input z. In this case, the witness encryption 
of Garg et al. [GGSW13] is not “succinct”: the size of the ciphertext Enc,.«(b) grows 
with the time to check the witness. Thus, the approach above gives us a non-succinct 
ABE scheme, where the size of a ciphertext depends on the worst-case runtime of any 
(allowed) Turing machine. 

To obtain succinctness, we use a SNARG scheme [BCCT13]. A SNARG has a 
common reference string crs, which is assumed to be securely generated. Any user can 
prove any NP statement by computing a proof 7. The length of the crs, the length of 
the proofs, and the time to verify a proof are all short: depending only on the security 
parameter, and not on the time to verify the NP witness. 

Enc,,« (b) now proceeds as follows. It generates a crs corresponding the underlying 
SNARG scheme. To encrypt a bit b w.rt. a public attribute x, it simply computes 
Encs» (b), where x* is now (x, crs, VK). A valid witness for x* is a tuple of the form 
(M,o,7) where ø is a valid signature of the Turing machine M, and 7 is a succinct 
SNARG proof that M(x) = 1. The fact that 7 can be verified in a short time makes the 
WE ciphertext succinct, as desired. 

This gives us an ABE for Turing machines. Because SNARKs are for NP, our 
resulting ABE scheme is for any class of Turing machines for which there exists a 
polynomial that upper bounds the runtime of all machines in the class. 

There scheme still has a slight drawback: it is succinct only for uniform Turing 
machines. If the Turing machines have non-uniform advice as large as the runtime, 
the resulting ABE ciphertexts are non-succinct. We would like our ABE scheme to 
be a generalization of previous work on circuits, and in particular to be succinct for 
any non-uniform Turing machine. To this end, we replace the SNARG scheme with a 
SNARK scheme (succinct non-interactive argument of knowledge) scheme. SNARKs 
have the additional property that if an adversary A succeeds in proving that x € L, an 
extractor can extract a corresponding witness w from A. 

The final ABE scheme is as before, except that now a valid witness for x* = 
(x, crs, VK) is a pair (7, t) (without the Turing machine and the signature), where m is 
a proof-of-knowledge of a Turing machine M and a signature o such that ø is a valid 
signature of M and M(x) = 1. Now the witness size and the verification time is efficient 
(independent of the size of the Turing machine or its runtime). We refer the reader to 
Sec. 3 for more details on our ABE scheme and the security proof. 


Functional encryption for Turing machines. We use the reduction of Goldwasser 
et al. [GKP* 13] to construct a (single-key and succinct) FE scheme from FHE and 
ABE. Their reduction is for circuits so we need to adapt it to Turing machines. The 
main technical issue is that we need to perform the FHE evaluation of a Turing machine 
M. To achieve this goal, we construct a new Turing machine Mppe that evaluates 
homomorphically the transition function of M for a t number of times. The problem 
is that Mppe needs to know what inputs to read from M’s tape to feed into the FHE 


evaluation, but the movement of the head in M is an output of the transition function, so 
it is encrypted with FHE and unavailable to Mrye. To solve this issue, we transform M 
into an oblivious Turing machine using Pippenger-Fischer [PF79]: now the movement 
of the head follows a fixed and known pattern independent of the input to M. 

If one allows the runtime of M on x to leak, we can provide a second FE scheme FE* 
whose decryption algorithm runs in input-specific time. We construct FE* as a reduction 
from our FE scheme above using the idea of [GKP* 13]: instead of generating a function 
key skw for a Turing machine M, we generate many function keys skjy,,...,Sk Miog By? 
where M; is the Turing machine that runs M for 2° time steps, and either outputs the 
output of M or L if M did not halt in 2’ steps; the parameter Bp is a global bound on the 
runtime of the Turing machines we consider. To generate log B,, function keys, we use 
log Bn instances of our single-key functional encryption scheme above, by generating 
fresh keys for every instance of it. Moreover, since the underlying functional encryption 
scheme is for Turing machines, generating skm, can be done very efficiently, in time 
polynomial in the size of M;, independent on the runtime of M;. 

On input a ciphertext Enc(«) and a function key (skm, , - - - , SK Mog 5) for the Turing 
machine M, the decryption algorithm first tries to decrypt with skm, , then tries with 
skm, and so on. The first time that it succeeds it stops. Note that the runtime of this 
decryption algorithm depends on the runtime of M on the specific input x, denoted 
by tz. This is the case since it runs the original decryption algorithm (which runs in the 
worst-case) only with the secret keys skyy,,...,Skn4,,,,,> and all the Turing machines 
M,,..., Miogt, run in time at most tz. 

Reusable garbling and a variant of FHE for Turing machines. In our full version, 
we show how to construct these schemes from our FE scheme using a similar reduction 
to [GKPT 13]. 


Other related work. We discuss other related work in the full version of our paper. 


1.4 Paper Roadmap 


The rest of this paper is organized as follows. We provide definitions for extractable 
witness encryption and ABE in Sec. 2, and refer the reader to our full paper for other 
relevant preliminaries. Next, Sec. 3 presents our ABE scheme for Turing machines, 
which we prove formally in our full paper. Finally, Sections 4 and 4.2 show how to 
construct functional encryption for Turing machines. Due to space constraints, in our 
full paper, we present the construction of extractable witness encryption and prove 
the new assumption in the generic group model, we show that extractable witness 
encryption implies (weakly) obfuscatable point filter functions and deduce implications 
to obfuscation, and we present the construction of FHE for Turing machines. 


2 Preliminaries 


In this section, we define extractable witness encryption and ABE for Turing machines, 
and refer the reader to our full paper for definitions of FE for Turing machines, SNARKs, 
and other relevant preliminaries. 


2.1 Notation 


We let «x denote the security parameter throughout this paper. For a distribution D, we 
say x + D when x is sampled from the distribution D. If S is a finite set, by x < S, 
we mean x is sampled from the uniform distribution over the set S. 

We say that a function f is negligible in an input parameter «, if for all d > 0, there 
exists K such that for all x > K, f(k) < k~%. For brevity, we write: for all sufficiently 


large K, f(k) = negl(x). 


2.2 Witness encryption (WE) 


The syntax of WE is as defined by Garg et al. [GGSW 13], but the security definition has 
an additional extractability property. 


Definition 1 (Witness Encryption). A witness encryption for a language L € NP 
with corresponding witness relation Ry, consists of two polynomial-time algorithms 


(WE.Enc, WE.Dec) such that 


— Encryption WE.Enc(1", x, b): takes as input a security parameter K, x € {0,1}* 
and a bit b and outputs a ciphertext ct. 

- Decryption WE.Dec(w, ct): takes as input w € {0,1}* and a ciphertext ct and 
outputs a bit b or the symbol L. 


Correctness: For all (x,w) € Rt, for all bits b, for every sufficiently large security 
parameter kK: 


Pr{ct + WE.Enc(1*, a, b) : WE.Dec(w, ct) = b] = 1 — negl(k). 


Definition 2 (Extractable security). A witness encryption scheme for a language L € 
NP is secure if for all p.p.t. adversaries A, and all poly q, there exists a p.p.t. extractor 
E and a poly p, such that for all auxiliary inputs z and for all x € {0,1}*, the following 
holds: 


Pr[b + {0, 1}; ct + WE.Enc(1", x, b) : A(a, ct, z) = b] > 1/2 + 1/q(|a]) 
=> Pr[E(z,z) =w: (a,w) € Rz] > 1/p(|z|). 


2.3 Attribute-based encryption (ABE) for Turing machines 
We define the syntax and security of ABE for Turing machines. 


Definition 3 (ABE for Turing machines). An attribute-based encryption scheme ABE 
for a class of Turing machines T is a tuple of four algorithms (ABE.Setup, ABE.KeyGen, 
ABE.Enc, ABE.Dec), the first three of which are p.p.t., such that: 


— ABE.Setup(1") takes as input the security parameter 1" and outputs a master public 
key mpk and a master secret key msk. 

— ABE.KeyGen(msk, M) takes as input the master secret key msk, a Turing machine 
M € T, and outputs a function key skm. 


— ABE.Enc(mpk, x, b) takes as input the master public key mpk, an attribute x € 
{0, 1}*, and a bit b and outputs a ciphertext ct. 


— ABE.Dec(sk m, ct) takes as input a key sk ņ and a ciphertext c and outputs a bit. 


Correctness. For all Turing machines M € T, for all attributes x € {0,1}*, for all bits 
b, for K sufficiently large, 


Pr[(mpk, msk) + ABE.Setup(1*); fsk s + ABE.KeyGen(fmsk, f); 
c + ABE.Enc(fmpk, x) : ABE.Dec(fsk, 1’, c) = f(2)] 
= 1 — negl (x). 


Efficiency. There exists a polynomial p such that the running time of ABE.Dec(sk m, ct) 
is at most p(k, runtime(M, x)). 


The efficiency property states that the work of the decryption depends on the run time 
of a Turing machine on the attribute. Since ABE.Setup, ABE.KeyGen and ABE.Enc are 
p.p.t.-s, their running time depends only on the security parameter and not on the running 
time of the Turing machines (except for a logarithmic dependency on it). 

Our security definition is full (the adversary can choose the challenge attribute based 
on the public key) and non-adaptive (the adversary chooses the Turing machines before 
getting the challenge ciphertext). 


Definition 4 (Attribute-based encryption security). Let ABE be an attribute-based 
encryption scheme for a class of Turing machines T and let A = (Aj, A2) be an 
adversary. Consider the following experiment. 


Expage(1"): 


: (mpk, msk) + ABE.Setup(1”) 

: (x,state) + ABBE KeyGen(msks-) (mk) 

: Choose a bit b at random and let ct + ABE.Enc(mpk, x, b). 

: b' & Ag(state, ct). 

: If, b = b and for all Turing machines M that A requests to oracle 
ABE.KeyGen(msk, -), we have M (x) = 0, output 1, else output 0. 
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We say that the scheme is a secure attribute-based encryption for Turing machines if 
for all p.p.t. adversaries A, and for all sufficiently large k: 


Advape,A := | Pr[Expage.a(1") = 1] — 1/2] = negl(x). 
3 Attribute-based Encryption for Turing Machines and RAMs 
We construct an ABE scheme for Turing machines based on three ingredients: 


1. an extractable witness encryption scheme WE = (WE.Enc, WE.Dec) based on the 
work of [GGSW 13], on which we elaborate in Sec. 2.2, 


2. asuccinct argument of knowledge scheme, SNARK = (SNARK.Gen, SNARK.Prover, 
SNARK. Verify), based on the work of [BCCT13], 


3. anexistentially unforgeable signature scheme secure against adaptive chosen message 
attacks SIG = (SIG.KeyGen,SIG.Sign, SIG. Verify) [GMR88]. 


Theorem 5. Assuming the above three primitives, there exists a secure attribute-based 
encryption scheme (as per Def: 4) for any class of (uniform or non-uniform) Turing 
machines T, for which there exists a polynomial p such that the runtime of every machine 
in T is upper-bounded by p. 


The p restriction comes from the fact that SNARKs are for NP. From now on, 
for brevity, we will refer to such a class by “a class of Turing machines with runtime 
upper-bounded by some polynomial". 


Corollary 1. There exists a secure attribute-based encryption scheme for any class of 
(uniform or non-uniform) Turing machines whose runtime is upper-bounded by some 
polynomial under the extractable DGE No-Exact-Cover assumption, “knowledge of 
exponent assumption”, and the existence of collision-resistant hash functions (Sec. 1.2). 


3.1 Construction preliminaries 


We advise the reader to recall the intuition we provided in technique overview, Sec. 1.3. 


The language L for SNARK. We define L by defining its relation, Rz. Let Rz be 
the following instance-witness relation: the instance is of the form y = (VK, z,t) 
(a verification key VK for a signature scheme, an input x, and a time bound t) 
and the witness is of the form w = (M,c), for M a Turing machine and o a 
signature. Then, (y,w) € Rz iff SIG.Verify(VK, M,o) = 1 and M halts on x in 
at most t steps and outputs one. Moreover, t < p(|x|), where p is a polynomial 
upper-bound on the runtime of every Turing machine in the class of interest. Let 
(SNARK.Gen, SNARK.Prover, SNARK. Verify) be a SNARK system for L. 


The Language L* for WE. Based on the above language L and the SNARK system 
(SNARK.Gen, SNARK.Prover, SNARK.Verify) for L, we define a language L* for the 
witness encryption scheme using the witness relation Rz» as follows: 


Rr» |x* = (x, crs, VK), w* = (7, t)] = 1 iff SNARK.Verify(crs, (VK, x,t), 7) = 1. 


Let WE = (WE.Enc, WE.Dec) be an extractable witness encryption scheme for the 
witness relation Rg». 


3.2 Construction of ABE for Turing machines 


Our construction of ABE = (ABE.Setup, ABE.KeyGen, ABE.Enc, ABE.Dec) for Turing 
machines proceeds as follows. Let 7 be the class of (uniform or non-uniform) polynomial 
time Turing machines for the ABE scheme. 


Setup ABE.Setup(1") where « is the security parameter: 


1. Sample a verification key / signing key pair (VK, SigSK) + SIG.KeyGen(1"), and 
output mpk := VK and msk := SigSK. 

Encryption ABE.Enc(mpk, x, b) where mpk = VK, x € {0,1}* and b € {0, 1}: 

1. Run the SNARK generator SNARK.Gen to get crs + SNARK.Gen(1"). 

2. Let x* = (x, crs, VK). Compute ctwe + WE.Enc(1", 2*, b). 

3. Output ct := (a*, ctwe). 

Key generation ABE.KeyGen(msk, M) where M is a Turing machine: 

1. Compute o + SIG.Sign(SigSK, M) and output sky := (M, 0). 

Decryption ABE.Dec(sk m, ct) where sky = (M, o) and ct = (a* = (x, crs, VK), ctwe): 


1. Run M on z and let t be the number of steps after which M halts (note that M is 
a polynomial time Turing machine so it must halt within a polynomial number of 
steps). 


. If M(x) = 0, output L and exit. 

. Otherwise, let w := (M, c) and note that ((VK, x,t), w) € Rr. 

. Run SNARK. Prover to obtain a proof 7 + SNARK.Prover(crs, (VK, x,t), w). 
. Let w* = (m, t). Compute and output WE.Dec(w*, ctwe). 
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Proof Intuition. We prove Th. 5 formally in our full version, and we only provide 
intuition here for the security proof. We start by assuming the ABE scheme is not 
secure, and reach a contradiction by showing that one can forge signatures using the 
extractability properties of the WE and SNARK schemes. Therefore, assume there is 
an adversary for ABE, Aage = (Aape,1, Aape,2). We will show how to construct an 
adversary Awe for the WE scheme: Awe simply embeds its challenge ciphertext into 
the ciphertext for Aage and lets Aage decide. 

Once we have the adversary Awe, by the security definition of WE, we also have an 
extractor Ewe which on input x*, outputs a valid witness w* = (7, t) of (2*,w*) € Rr». 
Using Ewe, we construct a prover P* for the SNARK system that is able to construct 
an instance y = (VK, x,t) and a proof 7 for which the SNARK verifier accepts. By 
the proof of knowledge property of the SNARK, there exists an extractor Esnark 
that outputs a witness for the SNARK language L, namely w = (M,o), such that 
(y,w) € Rz. This means that M(x) = 1 and that ø is a correct signature on M; but 
Aapee only asked for signatures of Turing machines M; for which M/;(x) = 0. Therefore, 
(M, c) are a new signature pair and thus we used P* and Esnarx to forge a signature 
and reach a contradiction. 


3.3 ABE for RAMs 


In this section, we discuss how to construct ABE for RAMs. This construction is similar 
to our construction for Turing machines, so we only mention the main differences here: 
the language L for the SNARK and ABE.KeyGen. See our full paper for more details. 
Let (M, D) be a RAM pair: a RAM machine M and memory D. 


The language L for SNARK. Let Rz be the following instance-witness relation: 
the instance is of the form y = (VK,z,t) (a verification key VK for a signature 
scheme, an input x, and a time bound t) and the witness is of the form w = 
(r, M, or, m) S, {t, Di, O(r,i,D,) }ies), Where r is a nonce, M a machine, o(m,r) is 
a signature on the description of the machine M and the nonce r, S is a set of integers 
that represent memory addresses (the memory accesses M makes to D), D; is the value 
in the i-th slot of memory and or; p; is a signature on r and D;. Then, (y, w) € Rz iff 

1. SIG.Verify(VK, (r, M), o(r,a2)) = 1, 

2. SIG.Verify(VK, (r, i, Di), o(r,p,)) = 1 for alli € S, 

3. M halts on x in at most t, all of its memory queries are in S, and outputs one. 


Key generation ABE.KeyGen(msk, M, D) where M is a RAM and D its memory: 
1. Choose r + {0, 1}?°"), 
2. Compute o(,,.7)  SIG.Sign(SigSK, (r, M)). 
3. For every i €1...|D|, compute o(,.;,p,) <— SIG.Sign(SigSK, (r, i, D;)). 
D 
4. Output (r, M, O(r,M)> {D;, dbs Wea): 

Key generation runtime and the function key size are polynomial in the description 
of the RAM and the size of | D|, but they do not depend on the runtime of the RAM. (As 
a remark, to obtain a slightly shorter key size, one can sign a Merkle tree over the entries 
in D.) The time to decrypt also only depends on the time to run the RAM and not on its 
worst case running time or on the memory size. 


3.4 Beyond ABE for Turing machines and RAMs 


Interestingly, it turns out the expressivity of our ABE construction goes beyond that of 
Turing machines and RAMs. The ABE construction can be easily changed to allow the 
evaluator to provide an additional input a to the computation. That is, given a function 
key skm, a ciphertext ct, j, an evaluator can choose an input a by himself; then if 
M(a,a) = 1, ABE.Dec outputs m, otherwise, it outputs |. To construct such an ABE, 
one only has to change the SNARK language L such that an instance has the form 
(VK, x,t) and a witness is (M, o,a) with M (x,a) = 1 and o verifies M. 

This extra input a makes the scheme significantly more expressive. We illustrate on 
two examples. The first example allows the secret key owner to delegate the choice of 
Turing machines to another user, say Alice, by issuing a function key for Alice; then Alice 
can choose Turing machines of her choice to run on the ciphertexts, without contacting 
the secret key owner. To construct this example, the secret key owner generates sky,,,. 
where Uajice iS a universal circuit containing Alice’s public key. Uajice takes as input 
a = (TM,o(TM)) and z: it first checks that o(TM) verifies with Alice’s public key as 
being a signature of TM, and if so, it runs TM(2:). Now Alice can choose any Turing 
machine TM she wishes, and as long as she signs it, she will be able to evaluate it on the 
ciphertext. In fact, the secret key owner can delegate the choice of Turing machines to 
any group of people, and he can even express complex policies, e.g. “allow any Turing 
machine that is signed by (Alice and Bob) or Chris”. 

The second example is to run any approved RAM on any approved database, where 
approved means that it was signed by the secret key owner. We do not elaborate further 
on this construction and its applications in this short paper version. 


4 Functional encryption for Turing machines 


In this section we construct a (single-key and succinct) functional encryption scheme for 
Turing machines. We refer the reader to our full paper for a definition of FE for Turing 
machines. 


Theorem 6. Assuming we have: 


— an attribute-based encryption scheme for any class of (uniform or non-uniform) 
Turing machines with running time upper-bounded by a polynomial, and 


— a fully homomorphic encryption scheme, 


there is a (single-key and succinct) functional encryption scheme for any class of (uniform 
or non-uniform) Turing machines with running time upper-bounded by a polynomial. 


Theorem 7. Assuming there exists a (single-key and succinct) functional encryption 
scheme for any class of (uniform or non-uniform) Turing machines with running time 
bounded by a polynomial, there is a (single-key and succinct) input-specific runtime 
functional encryption scheme for any class of (uniform or non-uniform) Turing machines 
with running time bounded by a polynomial. 


Corollary 2. There exists a secure (single-key and succinct) functional encryption 
scheme FE and a (single-key) input-specific runtime functional encryption scheme FE* 
for any class of (uniform or non-uniform) Turing machines with runtime bounded by 
a polynomial under the extractable DGE No-Exact-Cover assumption, “knowledge of 
exponent assumption”, and the LWE assumption with circular security (Sec. 1.2). 


4.1 FE for Turing machines construction (FE) 


Recall the construction overview provided in Sec. 1.3. We follow the reduction of 
Goldwasser et al. [GKP* 13] who showed how to construct a (single-key and succinct) 
functional encryption scheme from any ABE and FHE scheme, where functions were 
modeled as circuits. 

Our construction of FE = (FE.Setup, FE.KeyGen, FE.Enc, FE.Dec) proceeds 
similarly to the [GKP* 13] construction, with the main difference being that we work 
with Turing machines instead of circuits. There are two places in the reduction where 
the treatment of circuits is different from the treatment of Turing machines: in the use 
of the ABE and FHE schemes. To adapt the reduction to Turing machines, we first use 
our ABE for Turing machines scheme. Second, we need to construct a Turing machine 
Mrue that performs the FHE evaluation of another Turing machine M. We only present 
here the construction of Mppe and delegate the full FE construction to our full paper. 

Based on the intuition provided in Sec. 1.3, we describe a compiler Compileppe 
that takes as input a Turing machine M and a number of steps t and produces a Turing 
machine Mppe that computes the FHE evaluation of M for t steps. In the following, let 
& denote the FHE encryption of x. 


Algorithm 1 (Compilepy_ (1, t)) 


1. Use the Pippenger-Fischer transformation [PF79] for time bound ¢ to transform M 
into an oblivious Turing machine Mo with head movement function next. next is 
a function that takes as input 7, the current step in the computation, and outputs 
whether the head of Mo should move left or right on the tape. The Turing machine 
Mo has a transition function ô: ô takes as input a tape input bit b, a state state and 
outputs a new state state’, and the new content b’ for the new tape location which is 
indicated by next. 

Based on (Mo, next), construct a new Turing machine Mrye that takes as input an 
FHE public key hpk and an input encryption ĉ. Mrye evaluates homomorphically 
the transition function ô of Mo for t steps. Each cell of the tape of Mo corresponds 
to the FHE encryption of the cell value for Mrye. At step i, MrHe maintains the 
FHE encryption of the state of Mo at time i: state;. At step i, Mrppe takes as 
input the encrypted bit from the input tape Í that the head currently points at, the 
current encrypted state state;, and outputs an encrypted new state state; .1 and a 


new content b’. Mrue updates the current cell with b and then computes next(7) to 
determine whether to move left or right. 
. Output the description of Mrppe. 
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Note that the running time of Compileppe and Mfpe is polynomial in t. 


4.2 Input-specific runtime functional encryption for Turing machines (FE*) 


In what follows we show how to convert a (single-key) functional encryption scheme for 
Turing machines FE into one where the decryption algorithm, on input a function key 
for M denoted fsk and FE.Enc(MPK, z), runs in time that depends on the runtime 
of M on input z. Denote by FE* such a functional encryption scheme. We refer the 
reader to Sec. 1.3 for the construction overview and to our full paper for the definition of 
input-specific runtime functional encryption. 


Setup FE* Setup(1“): 


1. Generate T := log Bn independent pair of keys for the FE scheme: (msk;, mpk;) <— 
FE.Setup(1*). 


2. Output MPK := (mpk,,...,mpk,) and MSK := (msk,,...,msk,). 
Key Generation FE*.KeyGen(MSK, M): with MSK = (msk;,...,msk-;). 


1. Let M; be the Turing machine that runs M for 2’ steps and outputs M (x) if M 
finishes in that number of steps, otherwise, it outputs L. Let t; be the number of steps 
M; runs for.? 


2. Let fskm, < FE.KeyGen(msk;, Mi, ti), for? = 1...7. 

3. Output fskyy := (fskyy,,..., fskar_). 

Encryption FE*.Enc(MPK, x) with MPK = (mpk,,..., mpk_) 
1. Compute ct; + FE.Enc(mpk,, x) fori =1...7. 


3 Note that t; may be slightly larger than 2°, since t; is the number of steps it takes to simulate a 
Turing machine that runs for 2° steps. 


2. Output ct := (cty,...,ct-). 


Decryption FE*.Dec(fskm, ct): for fskm = (fskyy,,.-., fskm, ), ct =(cti, ..., Ctr). 


1. Starting with 7 = 1, repeat until v # L: 
(a) v © FE.Dec(fskaz, , ct;) 
(b) ic i+] 

2. Output v. 


Based on this construction, we prove Th. 7 in our full paper. 
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